/cc @kubernetes/patch-release-team @kubernetes/release-managers @kubernetes/release-engineering
/assign @tpepper

/cc @sumitranr

Do we need to upgrade github.com/containernetworking/cni package as well in k/k?

/hold

We need test evidence that this actually integrates (cluster lifecycle, scalability?).

Do we need to upgrade github.com/containernetworking/cni package as well in k/k?

No, the plugins and CNI libraries are independent.

/assign @claurence

@justaugustus given how close we are to the release for 1.15 I'm very hesitant to want to include this given CI Signal is stabilizing and I have concerns around risk this would add especially without info from SIG Scalability

Is there a reason we would really want to include this in the 1.15 release? if there is a very compelling reason (i.e. security) let me know - if not I'd want to defer for either a patch or 1.16

@tpepper / @claurence -- don't get me wrong; I get where you're coming from, but this might be endemic of a more sinister problem...

Do we ever have signal from the packages we cut?

There are several issues that suggest that we are not doing a great job of understanding this / exercising the toolchain:

• CNI cosmetics #113
• kubelet and kubernetes-cni packages depencies #310
• K8s 1.11.6 fails to install : Requires: kubernetes-cni = 0.6.0 kubernetes#75701
• CNI plugins (kubernetes-cni) build and packaging process improvements sig-release#245
• fix CNI to >= 0.6.0 for DEBs and RPMs #688
• kubeadm package should depend on the same version of kubelet and kubectl packages #3295

One of the questions in my mind is do we halt bumping/building packages (which may introduce security/bug fixes) because we're lacking signal or do we try to solve both problems at once?

I would argue that that's not a good reason to hold this up. Given the tooling we have today, we're only going to understand how these pieces work together after we build them.

The CNI plugins included here are used as part of kubenet. There haven't been any improvements in v0.8 that have to go in 1.15. So there's no need to rush this.

While I totally understand the desire to move quickly I don't have enough confidence this won't impact our release date and given the proximity to kubecon shanghai I'd like to keep things stable

Is there a reason this can't wait for a patch to go in? The urgency for this is not clear to me

I would argue that that's not a good reason to hold this up. Given the tooling we have today, we're only going to understand how these pieces work together after we build them.

Yes and no.

Almost all the time we have an associated SIG coming saying please update this dependency. On average the folks closest to each dependency make the argument for why the project should rev the dependency. Here I'd think that would be SIG Networking and SIG Cloud Provider and their subsidiary sub-projects making the push to change, with follow on vetting by SIG Release to insure the change timing makes sense and it doesn't surprise folks in SIG Cluster Lifecycle and SIG Scalability for example.

It will be awesome to have automation observing new versions of our machine readable dependency set and automatically pushing the changed set into a feature branch for full test validation. We will get there. In the meantime we have a lot of manual caution and discussion required.

@tpepper / @claurence / @squeed -- yep, you're totally right that this is not something that needs to land now.

I think I'm just expressing general frustration that this isn't something we can do today / is something that needs to be gated on release timing. I will code in anger to fix this 😝

/milestone 1.16

@justaugustus: Adding label: do-not-merge/blocked-paths because PR changes a protected file.

Bumped to v0.8.2, as @aojea mentioned there's a new version available.

@justaugustus: The following test failed, say /retest to rerun them all:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justaugustus

The full list of commands accepted by this bot can be found here.

The pull request process is described here

should we move this to 1.18?

/milestone v1.18

CNI 0.8.4 is out, but we're in the process of refactoring the rpm tooling in #1027, so I'm closing this out for now.

/close

@justaugustus: Closed this PR.

@justaugustus: PR needs rebase.